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(S4) Method and apparatus for long term verificalton of digital signatures 



(57) The time over whfcli a digital signature can be 
verified is extended wen beyond the expiration of any or 
all of the certificates upon which that signature depends. 
In a 'save state" approach, an archive facility is used to 
store public key hfrastnicture (PKI) state, e.g. crypto- 
graphic Information, such as certificates and certificate 
revocation lists (CRLs), in addition to non-cryptographic 
Information, such as trust policy statements or the doc- 
ument itself. This information comprises all that is nec- 
essary to re-create the signature verification process at 
a later time. When a user wants to verify the sign^ure 
on a document, possibly years later, a bng temr) signa- 
ture verification (LTSV) server re-creates the preciee ' 



state of the PKI at the time the document was orignally 
submllted. The LTSV sen/er restores the state, and the 
signature verification process executes the exact proc- 
ess it performed (or wouU have periormed) years ear- 
lier. Another embodiment ol the Invention combines the 
strength of cryptography with the proven resHience of 
(non-public key) technology and procedures currently 
associated with secure data stores by saving the PW 
state for future verification; and protecting the PKf state 
hformatfon from Intrusten by maintaining it in a secure 
storage faclCty which is protected by senrices, such as 
firewalls, accesscontrol mechanisms, audit facilities, in- 
trusion detectksn facilities. physk»l isolatkm, and net- 
work isolation. 
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Oeseripllon 

This invention relates to a method and apparatus 
for the long term verification of digital signatures. 

The technology of digital signatures opens up the 
likfil&iood of lncreased use of digital networks (including 
the Internet) for electronic commerce. It Is now f easble 
to send and receive digltalty signed documents that rep- 
resent transactions some value to one or more par* 
ties. 

Currently, a digital signature is veriTiabte only as 
long as the digital certificates upon which it depends 
have not spired. Given the expectation that a certiR- 
cate's life span is in the area of one to two years dura- 
Uon, current technology does not support the emerging 
needs of the electronic commerce market, where the du- 
rat}|lity of cfigital signatures over time is a requirement. 

For certain applications, the recipient of digitally 
signed documents should t^e able to verify the authen- 
tRily of a document years after the document was 
signed, just as the document's authenticity can be ver- 
ified at the time of siting. Unfortunately, the current 
state of the technology does not provide for the verTica- 
tlon of these digital signatures after oertificale expiration 
because it is the nature of keys and certificates used for 
signing and encrypting documents to expire after a spe- 
cific period of time (typically after a year or two). This is 
due, at least in pari, to the fact that the strength of keys 
is expected to degrade over time because of such fac- 
tors as improvements In computing speed and break- 
throughs in cryptoanalysis. Moreover, the k>nger the key 
is in use. the tonger that an adversary has to attempt to 
orack the k^. Therefore, it is standard piacttee to re- 
place keys periodically. This is why certffkates have 
specific expiration dates. 

An exanrtination of the current state of the technol- 
ogy reveals that a digital signature verification nKxJule 
wouki fail if presented with a request to vertfy a signed 
document in whk:h any of the associated certifk:ates had 
expired. Fig. 1 is a bk)ck schematic diagram illustrating 
certiwatton «cpiratton. This simple example demon- 
strates thai given a certificate 10 having a two^ear life 
span (e.g. from 4/1/96 to 4/1/98). a signature couki be 
successfully verified six months (e.g. on 1Qn/96) aner 
certificate issuance (100); but thissamesignature wouM 
not be successfully verified three years later (e.g. on 
4/1/99) (102). This behavtor is clearly unaccepteMe if 
the duration ol a document, for exampte contract, must 
extend beyond the duration of the certtficates' life. 

Further, some current systems use certificate revo- 
catkxi Ksts (CRL^) to revoke certificates and remove 
them therefrom* once those certKteates expire. This 
means that a record of those CRl^ generally disap- 
pears, making tong term signature verificatkxi impossi- 
ble using known technk^ues. 

It is known to reconstruct past tnjst (see A. Menez- 
es. R van Oorschot. S. \fanstone. Handbook of Applied 
CrvptoQfaphv. CRC Press, pp. 583 (1996)). In this ap- 



proach., both signature reverffication relative to a past 
point in time and resolutkm of disputes may require re- 
oonstnictkm of chains of tmst from a past point in time. 
This requires archival of keying material and related in- 

5 fornr\atk)n for reconstmctkxi of past chains of tmst. Di- 
rect reeonstructbn of such past chains Is taught to be 
unnecessary If a notarizing agent is used. A notarizkig 
agent is defined as a general service capable not only 
of ascertaining the existence of a document at a certain 

10 time, but of vouching for the truth of nrxm general state- 
ments at certain points In time. The original verifk»tkxi 
d the notary is taught to establish the exist^toe of a 
tnisl chain at that point in time, and eubsequendy its 
record thered is taught to serve as proof of prior validity. 

IS It Is taught ^at details of the original tnjst chain may be 
recorded for audit purposes. It is not taught that a doc- 
ument can be verified based upon the existence of ex- 
pired certificates. Ftather. reliance Is placed upon the 
use of the notarizing agent. It is further taugjht that the 

20 archived keying material can be used as evidence at a 
future time toaltow resolutkxi of disputed signatures by 
non-automated procedures. 

It woukJ be advantageous to piwkle a fechnk|U6 for 
extending the tkne over which the aulhentidly and h- 

25 tegri^ofdigitalsfgnaturescanbeaccuralelyvarifiedbe- 
yond the tinne that any relevant certlficatas expira. 

The present invention seeks to provkle improved 
sigrmture verification. 

Accordirig to an aspect of the present invention 

30 thereis providedamelhodof enabling kxig term verifi- 
catkxi of digital signatures as specified in daim 1. 

According to another aspect d the present onven- 
tion there is provMed apparatus as specified in dawn 11 . 
The pref ered embodinmnt provkfes a method and 

ss a9)paratus vMkh effectively extends the time over which 
a digital signature can be verified, Le. well beyond the 
expiratkxi of any or al of the certflcates upon which that 
signature depends. The inventkxi can to used lor any 
^ycatton domain where users want digital signatures 

40 to be applied to bng lastir^ documents (e.g. contracts), 
and be independently verifiable years or decades after 
signing the document The preferred embodimenftpio- 
vkjes two altemallve approaches to oonstnicting a so- 
lutkxi whteh delivers tong term signature verificatton 

45 (LTSV). 

One embocfiment d the invention provktes m ap- 
proach for solving the LTSV problem ttiat Is referred to 
herein as the 'save state' approach. This embodbnent 
d the inventkm largely entails the use d cryptographk: 

so infomnation and techniques. Thus, an archive tadtity is 
used to store the public key infrastructure (PKI) state, 
B.g. cryptographic information, such as certificalee and 
CRL6, in additkvi to the dooumsnt iteeV. This informa- 
tion comprises all that is necessary to recreate the slg- 

ss nature verifrcatjon process at a later time. It may also be 
desirak>le to store tlie source document separately from 
the cryptographic information (such as the signature, 
certifkiates. and CRljs) for reasons d privacy, fdr ex- 
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ample, a user may want to have control over the source 
document. The PKI state infomelion may contain either 
or both of cryptographically protected infomnation, such 
as certincates and CRLs. and infomnation thai is not 
cryptographicaily protected, such as the public key of a 
root certification authority or policy information. 

When a user wants to reverify the signature on a 
document, possibly years later, an LTSV sener re-cre- 
ates the predse state of the PKI at the time the docu- 
ment was originally submitted. The LTSV sewer re- 
stores the state, and the signature verification process 
exectites the «cact process it perfomied (or would have 
performed) years earlier. The lime used as the basis for 
re-creation of the signature verification process does not 
have to be the time of submittal Rather, the time could 
be some other relevant time, such as when a document 
was signed by the originator or when it was verified by 
a recipient. 

Another embodlmenl of the invention combines the 
strength of cryptogr^hy wfth the proven resiltenoe of 
(non-pubiic key) technology and procedures currently 
associated with secure data stores. An example of this 
embodiment provides a mechanism that 

• Saves the PKI state for futura reverification; and 

• Protects the PKIrstate infomnation from intrusion by 
either maintaining it in a secure storage facilfty 
which Is protected by sen/bes. such as firewalls, ac- 
cess control mechanisnrts. audB faciRies, intmslon 
detection facilities, physical isdatbn. and network 
isolatbn; and/or employing a cryptographic protec- 
tion mechanism, for example using the LTSVs^er 
to sign the PKI state information or using a keyed 
hash algorithm. 

In addition, other non-cryptographic features may 
be added to such approaches to defiver a highly secure 
and tnjsted LTSV solution, including, for example utiD- 
tles for viewing the PKI state information (cryptographk; 
as well as non-cryptographic) and visually monitoring 
the security of the system. These utilities can be used 
to provide visual evkience for purposes of dispute res- 
olutton. 

One enhancement to ^e secure storage approach 
herein disclosed maintains certain evidence, such as 
certifksate chains, m an archive. This Infomnation need 
not be used for actual reverifk»tk>n, but merely as sup- 
porting evkience in case of a dispute. 

An embodinnent of the present invention is de- 
scribed below, by way of example only, with reference 
to the accompanying drawings, in vfhich: 

Fig. 1 is a block schematic diagram Illustrating cer- 
tificatton ecpiration; 

Fig. 2 is a block schematic diagram illustrating a 
-save state' embodiment of Ihe inventbn; 



Fig. 3 is a bbck schematic diagram iDustrating a 
"save stale' "secure storage* embodiment of the in- 
vention: 

s Rg. 4 is a flow diagram that provides two altemative 
scenartos that illustrate the appScability of time 
stamps to the preferred embodiments; 

Figs. 5a-5c provkie bbck schematic diagrams that 
10 illustrate three long tenm signature verificatkNi us- 
age scenartos; . • 

Fig. 6 is a block schematic diagram thai ilhistiates 
tnjsl between two entities ; and 

IS 

Fig. 7 is a bbck schOTiatic diagram that Illustrates 
a long term signature verifkstton trust model. 

The meanings of some of the terms used iierein 

so may differ somev^at from c o m mon usage. The fdiow- 
Ing def Inltbns are meant to clarify the meaning cH each 
in the context of its usage herein. 

Archive: Any fadlity for the storage and retrlevai of 
electronic informatk>n. 

2S Certifk»te: An artifact upon which digital signalurM 
are based. A certificate securely binds an entity with that 
entity's pubRc key. 

Cryptographic (Refresh: A means of solving the key 
degradation problem wtien storing cryptographic Infor- 

30 matbn for tong.periods of tima The process involves 
re-encoding the old cryptographic artifacts (e,gt en- 
crypted data, digital signatures, and message digests) 
with stronger algorithms and/or longer keys. 

Document' A document can be any infomnatkih 

3S which can be represented electronicdly or optically (b. 
g, an arbitrary bit stream). 

Key Degradatk}n/Algiorithm Degradation: The proc- 
ess whereby the proiectksn afforded a document ^ en- 
cryption under a key k)ses eff ^tiveness over time. For 

40 example, due to factors such as improvements in com- 
puting speed and breakthroughs in ciyptoanalysis. H is 
expected that a document securely encrypted today 
would be crackable years later. This property could af- 
fect any ciyptographrc infomnaikxi, indudv>g digital slg^ 

^ natures. This problem can be generalized to keyed and 
non-keyed cryptographic processes and anifacis, sudi 
as one-way hash algorftlms. The security provided by 
these are also expected to diminish over time. 

LTSV. Long Term Signature Vertficafm. The herein 

so described method and apparatus for verifying a digital 
signature after the certificates used for such verlficatnn 
liave expired. 

LTSV client: The entity which requestsAililizes the 
services of the LTSV server. 

ss LTSV server The entity which delivers the LTSV 
sen/ices. This does not vnply, however, tiiat tliis entity 
must be stand-atone component. 

LTSV submission: A request from an LTSV client to 
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an LTSV server to perform the necessary functions re* 
quired to enable reverifjcation of a digital signature 
some time in the future (e.g. save PKl state). 

PKI: Public Key Infrastructure. Refers. to all compo- 
nents, protocols, algorlthnns. and interfaces required to s 
deliver the capabilities to digitally sign and verify docu- 
ments. For purposes of clanly herein, a PKl does not 
Include a service module lor long term signature verify 
cation (LTSV sender), although in practice a PKl might 
be designed to encompass such a module. 10 

Signature Reverifjcation: The re-creation of the dig- 
ital signature verificatbn process after the original veri- 
fication. This specificafly refers to the process associat- 
ed with the verificatbn process, based upon the resto- 
ration of Ihe previously saved PKl state. is 

Signature Verification: The process by which a dig- 
ital signature, for a given document, is determined to be 
authentic or not 

Signature Verification Module: The module which is 
responsible for performing the veriHcation of digital sig- ^o 
natures. 

Time stamp: A digital time stamp is an electronic 
indicator which associates the current date and time 
with a particular docunnent. Tone stamps are useful for 
proving that a document existed at a particular time. It ss 
is desnable that time stamps be secure, durat>le over 
time, and trusted by those using them. 

The discussion herein assumes an understanding 
of pd^lic key, digital signatures, and PKl infrastructure 
using X.509 certificates. Practical information concern- 90 
ing application of such techniques Is considered to be 
well krwwn to those skilled In the art. Background infor- 
mation may be found, for example, in B. Schnier. Ap- 
plied Crvptooraphv: Protocols. AkiorTthnr». and Source 
Codeine . John Wiley & Sons, inc. (1 996); W. Ford. M. 3S 
Baum. Secure Electronic Commerce . Prentice IHafl PTR 
(1997); and in the X509 v.3 specifk»tton OX509-AMI 
ISQnECJTC1/SC21, E)rBft Amendments DAM4to ISO/ 
lEC 9594-2. DAM 2 to ISQ/IEC 9594^, DAM 1 1D \SOf 
lEC 9594-7. and DAM 1 to fSCVlEC 9594-B on Ceitifi- 40 
cale Extensions, 1 December 1996). The system de- 
scribed herein may be buOt upon the X509 infrastnjc- 
ture. 

The following discussion provktes some back- 
ground on cryptographic techniques. Cryptographic al- 45 
gorithms can generally be divkJed Into two categories: 
pubOc key (e.g. RSA) and secret key (e.g. DEB). Both 
types of algorithms transform plain text into cypher text 
using a k^(s) for the encryption and decryption proc- 
esses, so 

Both pubtb key and secret key algorithms are con- 
sidered to be secure. One is not better than another In 
terms of security. The strength of each algorithm, in 
terms of it being cracked, is largely a functkxn of the 
length of the key used. The primary distinguishing char- ss 
acteristic of public key. however, is that It uses two keys 
(one to encrypt and another to decrypt), while secret key 
algorithms use only one key (the same key is used for 



encryption and deciyption). For this reason, secret key 
algorithms are sometime referred to as symmetrlc algo- 
rithms and publk: key algorithms are called asymmetric. 

One problem wlh secret key algorithms is that a key 
must be dlstrbuted between ail partclpants. This means 
that some secure channel must be available for the dis- 
tributic^of thekeys. 

In practk:e, each entity ina pubfic key-based system 
has a key pair, Le. one private key and one public key. 
The private key is known only to its owner, the public 
key is known k> all correspondents. It is computationally 
inf easible to determine a private key from the public key. 

The two primaiy sendees provktod by pubUe key 
cryptography are secure exchange of symmetric keye 
(by using public key techniques to encrypt a symmetric 
S6sste>n key), and non-repudiation via digital signatures. 

Publk: key cryptography can be used to solve the 
key exctiange problem associated with secret key algo- 
rithms by using this technology to encrypt the sscr^ kay 
under the public key of the recipient. It can then be de- 
crypted by the recipient using his/her private key. 

Digital signatures are possible by encrypting data 
with the private key ol the signing entity. Any entity can 
decrypt it with the signer's publicly available public key 
end krKvw that no one else couM have encrypted it be- 
cause that private key is only known by that one individ- 
ual. This particular use of pubfic key provMes the non- 
repudiatnn senrice. which is a primary use of put>lk^ key 
cryptography. A digital signature is very powerful notbn, 
it generally exhibits the following characteristics: 

• Cannotbeforgedt 

• Is independently verifiable; 

• Is not reusable or transferable to a different piece 
of data; and 

• Indudes data integrity checks, albwing tamper-de- 
tectbn. 

The new senfices provided by public key cryptog- 
raphy do not come for free, however, because these 
services reqiiire the existence of a supporting public key 
Infrastructure. The strength of a public key system de- 
pends upon the assurance that an participants know the 
publb key of any entity with whom they wish to oone- 
spond. If a secure oom»spondence between a user and 
his/her public key cannot be maintained, then It may be 
possible to impersonate another entity or read encrypt- 
ed data intended for another. 

The standard solutbn to this problem Is the issu- 
ance of a digital certificate p(.509 certricale) to each 
partbipant. This eertricate securely binds Its owner's 
name with his/her public key It is issued by a trusted 
third party, called a certifkalbn authority (CA). and is 
signed by that CA. thereby making it tamper prexsf . Cer- 
tifk:ates are issued for a limited period cA lime (start and 
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stop dates), during which the certificate is considered 
valid. Acerttficate is considered ^iredafterthe ending 
validity date. 

The public keys of entities (which are enrxbedded in 
the X.509 certificates) must be publicly available. The 
distribution or access mechanisins available are numer* 
ous. 

The secure operation ol a publ'c key Infrastructure 
rests upon certain points ol trust Certainly each entity 
must trust its own CA. However, when a given PKI do- 
main is expanded to encompass relationsh^ with mul- 
tiple C As. the number of points of trust are also expand- 
ed. The trust placed in a partk:ular end entity (Le. that 
entity's certificate or signature) is cfredly related to the 
tnist relatkinships among the OAs which certify those 
entities. 

OAs can create trust relatk)nships with other CAs 
by certifying each other. This can be a unidirectional 
tnjst relatkxish^, whereby one C A can mere^ issues a 
certificate to another CA. just as a C A issues a certiFicale 
toan end user. Two CAs can alsomutuallyagreeto trust 
each other ^idirectonal trust relatnnship) by issuing a 
cross-oertrficate » a special form of certiftoale which 
contain two individual certificates, one for each direc- 
tbn. 

If two entities are In the sairo CA domain, then there 
Isnoconcem with respect to CA trust because they both 
tnist the BamB CA. This is not the case, however, when 
dealing virith the scenario where entRfes which have 
been certified by different CAs attempt to conduct a se- 
cure transaction. The security of thfe transaction de- 
pends upon the tnist between the CAs. More generally, 
the security provided by the PKI depends upon the trust 
models embodied in the tnisi lelattonshipe among the 
various CAs whidi choose to trust one another. In con- 
crete terms, any change in these tmst relationships can 
cause a signature verification to either succeed or fail. 

The preferred method and apparatus effectively ex- 
tend the time over which a digital signature can be ver- 
ified, Le. well beyond the explratk)n of any or aU of the 
certificates upon which that signature depends. They 
can be used tor any application domain where users 
want digital signatures k> be used on tong tasting docu- 
ments (e.g, contracts), and be independently verifiable 
years or decades after signing the document The pre- 
f en'ed embodiment ol the Inventton provides two alter- 
native approaches to constructing a solutksn which de- 
livers tong term signature verificatkx} (LTSV). 

Fig. 2 is a bk}ck schematic diagram illustrating a 
'save state' embodiment of the invention. This embod- 
iment, largely entails the use of cryptographic informa- 
tion and techniques. Thus, an archive facifity 20 is used 
to store a public key mfrastmcture (PKI) state 24, e.g, 
cryptographic Information, such as certificates and 
CRLS, in addition to the source document itself. For ex- 
ample, the LTSV client 25 requests the sen^bes d an 
LTSV sen/er 26 to accomplrsh storage of such informa- 
tion. This step is shown as the 'save state' step in Fig. 



Z The PKI state information may contain either or both 
of ciypto^raphlcaOy pfotected infomnation, such as cer- 
tlfk»tes and CRLs. and information that is not crypto- 
graphcal^ protec^^. such as the public key of a root 

5 certification authority or poJIcy informatbn. 

This information comprises all that is necessary to 
re-create the signature verifk:ation process at a later 
time, Le, during the 'restore state' step, for example, as 
requested by the LTSV client It may also be desirable 

10 to store the source document separately from the cryp- 
tographte informatk)n (such as the signature, certifi- 
cates, and CRLs) for reasons of privacy. For example, 
a user may want to have control over the source docu- 
ment 

IS When a user wants to reverify the signature on a 
document, possibly years later, the LTSV server 26 re- 
creates the precise state of the PKI at the time the doc- 
ument was originally submitted. The LTSV senwr re- 
stores the state, and the signature veriftoatton process 

20 28 executes the exact process it performed (or wouM 
have perfomied) years eariier. The time used as the ba- 
sis for re-creation of the signature veriFication process 
does not have to be the time of submittal. Rather, the 
time coukf be some other relevant time, such as when 

2S a document was signed by the Originator or »*»en it was 
verified by a recipient 

Fig. 3 is a bkxHc schennatic diagram ilHJStrating a 
'save state" 'secure storage' embodiment of the Inven- 
tion. This ennbodiment ol the lnventk)n pombhes the 

30 strength of cryptograf^y with the proven resBience of 
(non-publk: key) technotogy and procedures currently 
associated with secure data storea An example of tNs • 
emixxfiment 

3S • Saves the PKI Slate for future reveriflcalion (as de- 
scribed above in connection with Fig. 2); and 

• Protects the PKI state Information from vitrusion by 
maintaining it in a secure storage facilSy which is 

40 protected by sen^, such as firewaDs. access 
control niechanisms, audit facilities, intniston de- 
tection facilities, physical Isolation, and networit iso- 
lation; and/or employing a cryptographic protection 
mechanism, for example using the LTSV sender to 

45 sign the PKI stErte information or using a Iceyed hash 
algorfihm. 

In addition, other non-cryptographic features may 
be added to such approach to deliver a highly secure 

so and trusted LTSV sdutton, Including, for example utili- 
ties 30 for viewing the PKI state Information (crypto- 
graphic as well as non-cryptographic) and visually mon- 
itoring the security of the system. These utilities can be 
used to provkie visual evidence for purposes of dispute 

ss resolution. 

One enhancement to the secure storage approach 
herein disclosed maintains certain evidence, such as 
certificate chains, in an archive. This infomretion need 
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not be used for actual reverification, but merely as sup- 
porting evidence in ca&e of a dispute. See A. Menezes, 
P. van Oorschol, S. Vanslone. Handbook of Aoplled 
Cnfl)toQfaohv . CRC Press, pp. 583<1996). for one man- 
ner In which this enhancement may be implemented in 
the context of a notary sennce (d'rscussed above). 

There are other embocfiments of the invention in 
which a hybrid LTSV solution could be constructed by 
combining cryptographic and non-ciyptographic tech- 
niques. The best combination for a particular apii^icatSon 
domain depends upon the security requirements of the 
application(6). in corhbinalion with cost constraints. 

ft is presently preferred to employ the second em- 
bodiment of the invention (discussed above) due to the 
cryptographic strength associated with its abDity to re- 
create the complete digital signature verification proc- 
ess, combined with the trust instilled by more conven- 
tional techniques used tor providing secure storage, and 
in conjunction with audit and viewing f aciiUies with which 
to view evidence arxj monitor trie secure storage con- 
trols, in practice, the most us^i embodiment of the in- 
vention fbr a particular application may be that which is 
the least expensive and which stll meets the user or ap- 
plication requirements. 

Several issues related to the design of a system 
which implements LTSV are described below. Alterna- 
tives for the resolution of the issues are presented, as 
well as a discussion of the advantages and disadvan* 
tages associated with each anematlve. 'The best ap- 
proach to any given solution depends upon the security 
requirements of the applicatlon(8) using the LTSV senf- 
ices, as well as the cost constraints. There is no t^est 
solution for all appBcations. 

When to Save the PKI State 

Signature rever^ication is preferably associated 
with a particular time because the outcome of this proc- 
ess could change, depending upon the state of the PKI 
(0.g, because of certificate revocations or the creation/ 
removal of cross certificates). There are numerous pos- 
slbifities with regard to when the PKI state should be 
saved, including: 

• At signature creation time, Thte approach is used 
when an individual wants to document the validity 
of his/her signature at the time it was created. This 
is the most accurate time to store the PKI stale be- 
cause it reflects the state at the time of signing, 
which Is presumably ttie critical lime in evaluating, 
the authenticity of that signature. Changes to the 
PKI state occur after that time, some of which could 
impact the outcome of a signature reverification. 
Therefore, saving of the PKI state at any time after 
signing introduces the possibility of inconsstencies 
between the slgrrer's and recipient's perspectives 
on a signature's validity. 



• At sicnature verification time. This approach Is use- 
ful when a recipient wants %o document the validity 
of a signed document received from another hdi- 
vidual. 

6 

• At archival time. When a user deddes that a docu- 
ment should be archived for long term storage is 
also an appropriate time to save the PKI state. 

• When exDlidtiv reouested. There mav occur certain 
application specific document Kle cycffs milestones, 
at which time the user may desire the PKI state to 
be saved for future reverification. 

• Just before chances in PKI state fao. certificate 
revoc^ton). This approach requires a tight integra- 
tion with the PKI because chariges in the PKI must 
tie monitored. 

^ The correct time at which to save the PKI state is 
preferably detemiined by the consUainls and needs of 
the application using the LTSV senricee. A robust LTSV 
solution is able to accommodate the needs of all (or 
most) applications in this respect. 

2S 

Contents of the PKI State. • 

The exact composition of the PKI state varies some- 
what from one PKI vendor's product to another's, de- 

30 pending upon tiie Imptementatbn chosen by each van- 
dor. Moreover, certain information is stored in a different 
format from one vendor to another. In addition, the con- 
tents of a PKI state may char^ over time as well, as 
new capabQities (and supporting data) are added to the 

9S system. Rnally, the required contents of the PKI state 
may change from one applanation to another, depending 
upon the needs (e,g. level of securi^ and legal require- 
ments) of each application. 

roolwtthstanding these uncertainties, there are 

40 dasses of PKI state infomiation which are candidates 
for saving. These classes include: 

• Certificate chain (list of certificates from one entity 
to another, including certification authorities (CAs) 

45 and the end entities). 

• CRLs (one for each CA in certificate chain). 

CA policy statements or idemiTiers. 

so 

• Attribute certificates. 

• Date and time. 

ss m Trust Infonnatton (e.g.. public lcey(6) or certificate(6) 
of tnisted root CA(s). policy constraints). 

Policy constraints are, for example, non-crypto- 
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graphic information stored within the LTSV archive. The • 
pubfic key of the taieted root CA may or may not be ciyp- 
tographically protected. If H is embedded in a certificate, 
then it is signed by the C A. However, it could just as well 
be an isolated public key, in which case it Is unprotected s 
by cryptography. 

U is possible that the items in the above list may not 
be supported or available from certain PKl implementa- 
tions. Further, the PKl state from another implementa- 
tion might Include some additional data. Therefore, the 10 
list above is only an example of what might be consid- 
ered Important pieces of PKl state information, ^n the 
current state of the technology. An implementation of an 
LTSV sennce is preferably tied to the implementalion of 
a specific PKl uhtn such time as Ihe technology evohres is 
and comprehensive standards emerge. 

How to Store the PKl State. 

Storage of the PKl state Is prelerabty accomplished » 
in either of two general ways: 

• Store all of the PKl state relevant to each document 

separately; and 

2S 

• Store the PKl state centrally, and only store ref er- 
encestothe PKl stale information with each docu- 
ment This approach enables storage efficiencies 
by eliminating the redundant stomge of PKl state 
information over multiple documents. For example, AO 
given two documents submitted to the LTSV sen/er 
at abou} t^e same time, rt is possible that the CRLs 
contained In the PKl state are exactly the earns tor 
both submissions. Central storage of this Infoima- 
tbnallowstheLTSVsen^er to store this information ss • 
only once. 

The storage requirements for the save state solu- 
tion lor LTSV may be quite large, depending upon the 
size of the certificates, the length of the certificate chains 40 
and - more importantly - the size of the CRLs. The 
choice of borage technique may have a great impact 
on the total data storage requirements. It is clearly un- 
desirable to store massive CRLs with every document 
that is stored for long term archival and possible f idure 45 
reverlfication. For this reason, the second alternative 
f istsd dbove Is presently considered to be the preferred • 
approach. 

However, this second approach may present cer- 
tain difficuBies in applications where the LTSV sender is so 
an entirely separate component from the PKl, and 
where support of multiple PKIs is a primary design goal 
of the LTSV sen^r. In this case, it would be advanta- 
geous for the PKl state to remain opaque to the LTSV 
sen/er, thereby providing ease of support of multiple PKl SS 
vendors. Given that what constitutes the PKl state for 
one vendor may be dlHerent for another verxior. it is de- 
sirable to maintain an opaque interlace between the 



LTSV server and the PKl. On the other hand, storage 
efTtciencles can be derived only if the LTSV senrer Is In- 
formed about the contents and format of the PKl state 
information. These conflicting requirements - accepta- 
ble storage size and opaqueness - pose a challenge 
for the design of an LTSV service. 

Some of the possible alternatives are listed below: 

• Keep the interface opaque and store the PKl state 
as it currently exists (full certificate chains and 
CRLs). This option focuses entirely oq the opaque* 
ness requirement, and sacrifices the data size re- 
quirement The prin^ry advantage of this solution 
is simplidly and quicic deployment. 

• Remove the opaqueness requirement by making 
the PKl stale visible to the LTSV sen/er. This allows 
the LTSV sen/er to manage the certificates and 
CRLs manually - thereby avoiding duplication of 
these ot>jects In Ihe data store. This solution poten- 
ttaOy sacrifices the ease of multi-vendor support at 
the ^qpense of aehievvig efficient etorage. 

Compromise by making the CRLs visS>le to the 
LTSV sender, where other PKl state Information is 
opaque. This solution Is interesting because it Is 
probable that the CRLs are the largest piece of data 
comprising the "PKK state. Because CRLs are stand- 
ard across nearly all PKIs. the vIsibDity should not 
pose a prcdslem in terms of multi-vendor support 
This solution address both of the requirements, but 
does put the burden of management of the CRLs 
onto the LTSV eenrer. 

An altemative embodiment of the invention pro- 
vides a variatk)n on the solutkm atxave that breaks 
up the PKl state into multiple pieces, each of which 
is opaque. The PKl indicates which of these objects 
Is common across multiple signsd documents (e.g. 
CRts and certificates). The PKl labels these ob- 
jects with un'que handles (ktentilierB). thereby al- 
k)win9 the LTSV server to store these objects and 
retrieve them effx^lently when needed for signature 
reverlfication - all the whie maintaining the 
opaqueness of these objects. 

Encourage PKl vendors to rrmke concise crypto- 
graphicaliy protected assertions about the state ol 
revocation, as an altemative to using CRLs. (For ex« 
ample, CRLs indicate who has been revoked It 
would be more efTicient if the PKl coukf make a 
statement that a certificate has not been revoked at 
a given point in time. This coukf eliminate the need 
for storing CRLs.) This approach Is non-standard, 
but acceptable because these PKI-generated as- 
sertions are not seen by any application outside the 
PKl. A major benefit of this approach Is that the 
opaqueness of the state is presented whUe some of 
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the storage inefficiencies of the state information 
are removed. 

♦ 

For cases where the LTSV server is dedicated to a 
particular PKI, it is preferred to create aclose integration 
between the two componertts, thereby allowing the 
LTSV sender to know about the content and format of 
the PKI state information, and store it in the most effl- 
cient manner po8sik>le. For cases where the LTSV send- 
er must be insulated from the PKI (e^. for portability 
across multiple PKIs), one of the opttons listed above 
(with the possible exceptbn of the first two) may be 
used 

Location of Source Data. 

The source data associated with an LTSV submis- 
sion can be stored either by the client or by the LTSV 
server itself. Some LTSV cientsdo not choose tosubmit 
clear text to the LTSV sender for storage because of con- 
cerns over privacy. (Privacy of the channel between the 
LTSV client and the LTSV senrer can be achieved by 
having the client encrypt the submission under the pub- 
lic key of the LTSV senrer.) A submission to the LTSV 
may be encrypted, such that the LTSV is not able to de- 
crypt it That is acceptable wilh the LTSV server. How- 
ever, the client must determine howto decrypt the sub- 
mission. 

Given that tiie LTSV server views the source data 
as a bit stream, it is possible that the message could be 
encrypted by the LTSV client before submission. (The 
fact that a general purpose LTSV server treats the 
source document as a bit stream does not preclude the 
possibility of implementing an application specific LTSV 
server that is aware of the contents of the sutsmitted da- 
ta.) The LTSV sender treats the encrypted data as the 
source. Such prior encoding may be sufficient for some 
applications* needs for privacy. In this case, however, 
either the client must maintain the decryption key, or the 
key must be divulged and stored by the LTSV server 
(which is probably not acceptable). 

Alternatively, the LTSV client may submit a mes- 
sage digest (resulting from a one-way hash fun^ton) as 
the source documertf. Thedient, in this case, is respon- 
sible for maintaining the real source document If the 
source document is stored by the client, then only the 
PKI state information is stored In the LTSV server's ar- 
chive (along with some reference lo the source docu- 
ment or the submitter). 

Whether the source data is stored by the client or 
the LTSV server, H must be produced If and when a 
reverification of that document is required. It is a re- 
quired component of any signature verification process. 

Kev and Aicorithm Degradation. 

11 cryptographically encoded information (e.g. digit- 
al signatures or encrypted data) is stored for a significant 



period of time, the issue of key and algorithm degrada- 
tion must be addressed, he. the probable loss in effec- 
tiveness of a cryptographic key or algorithm over time. 
Although signed documents are expected to be sealed 
6 securely with strong cryptographic a^orithms. the 
strength of an algorithm and associated key length de- 
creases over time with the advent of faster computers 
and new developments in cryptoanalysls. It is expected 
that cryptographic algorithms and key lengths have Ivn- 

^0 ited life spans. It is general^ acknowledged that they 
shouki be examined, modified, and^or replaced at peri- 
odic inten/als. This iegitlmale security concern increas- 
es with me length of time for whteh a document is valU, 
and ft becomes a very serious threal as the time span 

IS approaches muB^le decades. 

For example, a digital signature performed today, 
usir^ RSA and a 512-bit key, is considered very strong 
it wouM take years to forge It). But. it is also expect- 
ed thai this same signature may be easily forgeable 

£0, within ten yaare or so. This is because of the increased 
ability to search the key space faster (and thereby find 
the key used to sign the message) with newer comput- 
ers or oomputng techniques. Similarly, there may con- 
tinue to be developments in technk^ues for factoring 

^ large prime numbeis (the difficulty of whk^ Is the baas 
lor the strength of the RSA algorithm). It'is reasonable 
for both of these ablities to improve over Xtne (although 
the pace of these changes is less certain). 

It is, therefore, prudent to protect cryptographically 

30 encoded documents from this threat when those docu- 
ments must live beyond a few yeara. This the case 
with the documents expected to be submitted to the 
LTSV senrer. and especially so when using the save 
state approach herein disclosed. Hence, the LTSVfacfl- 

35 ity should address this problem. Mot^ only must the 
signed documents stored in the archive be protected 
from this threat, but all other cry ptographic data or meta- 
data stored in the archive should be protected. (The 
cryptographk: data primarily include keyed ^formation. 

^ That is, any Information that Is signed or encrypted wim 
a private key. Such information may also Include non- 
keyed cryptographic data, such as the output from a 
hash algorithm, such as MD5.) This data couU also in- 
clude such Items as certificates and CRLs, which are. 

45 themselves, digitally signed by the issuing CA. 

There are any number of ways Chat the LTSV faclGty 
addresses this problem. For example: 

• Periocfically countersign all data In need of ciypto- 
so graphic refresh through the use of nested signa- 
tures. Under this approach, the LTSV server effec- 
tively refreshes the cryptographic strength of the 
data by signing it with successively tonger keys (or 
stronger algorithms) every few years. Each counter 
ss signature has the effect of kx:king in the crypto- 
graphic strength of \he enclosed s^nature(s), 
theretyy extending the cryptographic life of the en- 
closed document. This countersignature is pr^era- 
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biy perlormed by the LTSV server using a key 
owned by that sen/er. Performance shortcuts may 
be required to avoid the costly unraveling of signa- 
tures at reverlfication time, or the potentially time 
consuming task of countersigning every document 
in the archive. Such shortcuts include* for example, 
removing a previous countersignature before ap- 
plying a new one, or countersigning the entire ar- 
chive or pontons thereof instead of each indivkiual 
document 

• A modification of the cryptographic approach sug- 
gested above provkles for countersigning the infor- 
matton in the archive once, but with an extremely 
tongkey, /.a akey which is expected to be unbreak- 
able tor decades or more. This eliminates all need 
forcoumerslgnlng. This may be merely a theoretical 
solution because finding an algorithm and key 
length which is secure for that long Is impossible to 
predict Therefore, there is still a need lo provide 
some backup mechanism, just in case the original 
algorithm were cracked, for example. 

• Protect the ciyplographto information in the archive 
by insulating the archive itself, rather than the indi- 
vidual documents contained in Uie archive, thereby 
eliminating the need for a cryptographk: solution. In 
this approach, the archive is protected via access 
controls and other procedural controls. If the ar- 
chive can l>e effectively Insulated from intruston and 
modificatksn, then key degradation is not an issue 
and cryptographic refresh is not necessary. 

• Use a time stamp facility to seat the cryptographic 
information in tima Such a facRity is expected to 
provide ail of the necessary characteristKe required 
for solving the key degradation problem. This time 
stamp facility couU use one of the techniques listed 
above, or it could even be an independent service 
(see below for a discussion of lime stamping). 

Relationship to Time stamping. 

A eecure and comprehensive LTSV solutbn prefer- 
ably includes an associatkxi with a time stamping mech- 
anism. For tong term verlRcatton of digital signatures, it 
Is often necessary to know the time at whksh partkrular 
events occurred (e.g. time of signing or verifying a sig- 
nature) to detemvne if a document was vaBd at that spe- 
cific time. If there were uncertainty concerning when a 
document was signed, then the later reveriftcation of 
that document oould be compromised because of the 
uncertainty of when it was signed. 

Fig. 4 is a flow diagram that provides two alternative 
scenarios that illustrate the applicability of lime stamps. 
- In scenarto 1: 

• Alice signs a document at time T1, and sends it to 



Bob (140). 

• Aide's certificate Is revoked at time T2 (142). 
s • Bob verifies Alice's signature at time T3 (144). 

inscenarto2: 

• Alice's certificate is revolted at time T1 (150). 

10 

• Alice signs a document at tvne T2. and sends a to 
Bob (152). 

• Bob verifies Alice's signature at time T3 (1 54). 

When Bob performs the veritk:atk)n (at time T3), he 
does not know when Alice signed the document. This is 
critical, because AJice*^ key (certifteate) were revoked 
before signing the message, then the signature veriflca- 
20 tion by Bob should lail. and Bob shouki not trust the con* 
tents of the message. If, on the other hand, the revoca- 
tion occurred after the act of signing, then the stgnaiure 
can be presumed to be valkj and trustworthy. For sim- 
pficity, this example does not conskler the complicating 
2S issue of CRL latency, Le. the time between the inUatian 
of certificate revocation and the lime when this infbrma- 
tion becomes available on a CBL 

This example demonstrates the need for a secure 
and trusted time stamp mechanism in the domah of cfig- 
so ttal signatures. The nriere recording of the current date 
and tkne when creating a digital signature is not sulfi- 
denl for most application because the source of ihal 
time may not be trusted by the recipient The impact, 
however, also applies not only to the short term signa- 
ls ture verifk:allon process, but also to the tong term veri- 
fication of digital signatures. Given the example above, 
the LTSV sender couM save the PKI state (at time T1) 
associated with scenarto 1 or scenario 2 (or t>oth). The 
outcome of a signature verificatton on this message 
40 years later is greatly affected by the PKI state used for 
this verification process, as weU as the target time for 
the verificatton. 

The prot>lem highlighted above demonstrates the 
preference that the LTSV service to be cognizant of 
45 fvne.ltehouM: 

• Be able to detennine in a secure fashion the time 
at which a document was originally signed; 

50 • Be able to reK^reale accurately the PKI state which 
was active at a target time in the past; 

• Be able to determine the current d^te and time ao- 
curateiy; and 



SB 

• At a minimum, save the PKI state associated with 
a particular target time. 
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These requirements estabfish the preference for 
the integration of a time stamp facility vynth the signing 
and verification (ancf reverificatbn) process. When a 
document is signed, it is also prieferabiy.time stamped 
to document in a secure fashbn the precise moment at s 
which that event occurred. The LTSV senfice should 
loiow the time for which the PKI state Is to be saved, be 
sure to save the appropriate state (the state active at 
the target time), and execute its signature reverificaUon 
process in the context of the correct time. io 

Usage Scenarios, 

Figs. 5a-5c provide blocit schematic diagrams that 
illustiaie three long temt signature verification usage is 
scenarios. 

In scenario 1 , a client (EntityA) 50 submits a docu- 
ment to a LTSV facility 52 for long term signature verifi- 
cation. This is a simple case where EntityA is interested 
In documenting that it possessed some piece of infor- ^ 
malion. 

in scenario 2. EntityB 56 receives a document from 
EntityA 54 and subnruts that document to the LTSV fa- 
cility 5B. In this case. EntityB wants to document that it 
received some information from EntityB. 2S 

In scenario 3, EntityA 60 sends the same document • 
to EntHyB 64 and to the LTSVfadlily 62. This case rep- 
resents a carbon copy feature, whereby EntityA can 
document the information it sent to EntityB by addition- 
ally filing it with the LTSV facQSy. so 

Each of the scenarios described above r^es is- 
sues with respect to encryption, private itey access, and 
trust models. 

EncwDtbn and Private Key Access. as 

A document can be encrypted anchor signed. Ide- 
ally, the LTSV facility accepts any such document This 
raises a problem, however, with respect to how the 
LTSV module works with respect to the encryption. 40 
When encrypting under a pubib Icey system, the docu- 
ment is effectively encrypted under the public Icey of the 
recipient, thereby guaranteeing that the recipient (the 
poseesaor ol the corresponding private key) is the only 
entity which can decrypt the information. (For purposes 45 
of this discussion, interaction with symmetric keys and 
algofitfims ignored.) 

When applying this principle to scenario 1 , it is dear 
that If the signed message is also encrypted, then it 
coukl be encrypted under the public key of the LTSV so 
module. This albws the LTSV component to unwrap the 
signed document and presence it for ksng Xem verifica- 
tkMi. This is a useful feature because it provides oonfh 
dentlality between EntityA and the LTSV senrice. This 
scenario does not preclude the possibility that the ss 
source documerrt sent signed and encrypted to the 
LTSV module could Itself be encrypted urxler a key 
known only to EntityA. That is, it is not necessary that 



I 

the LTSV have access to the plain text version of the 
source document. Th.e LTSV module treats that encrypt-, 
ed document as the source. If EntityA does decWe to 
encrypt the document first under a secret key before 
submilling the document to the LTSV senrice, then it is 
the responsibflity of EntityA to maintain possessfon of 
that key If and when deoyptbn of that document is re- 
quired. 

in Scenario 2, if themessage fromEntttyAtoEntityB 
is encrypted (under the public key of EntityB) and then 
forwarded - unchanged - to the LTSV sen/ice by Enli- 
tyB, then it is unreadable by the LTSV component be- 
cause it does not possess the private key required to 
decipher and unwrap the enclosed signed document. 
This unwrapping (deciphennent) is essential for the 
LTSV module to do Its job. 

There exist several alternatives tor addressing this 
problem: 

• AHow the LTSV facl% to have access to€ntiyB^ 
private key; 

• Do not alk>w EntityA to send encrypted documenis 
to EntityB: or 

• Have EntityB strip off the privacy aspect of the 
signed and encrypted document received from En- 
tityA. Because EntityB wants to preserve EntityA's 
signature on the document, and i>e able to verify it 
at a later time, this stripping process can not alter 
the validity of the signature. EntityA can then either 
send the strapped Clb, plain text) document to the 
LTSV sewlce. or it can re-encrypt it (still presenring 
the original signature by EntityA) under the public 
key ol the LTSV module. 

The latter approach above ispresentiy the preferred 
approach. The first approach above raises signifkrant 
security concerns because it requires distributton of an 
entrty*s private key. The second approach above is un- 
acceptably restrictive on the usage of the system. 

Trust. 

Digital signature verrication is always performed 
between two (and only two) entities. The vertftoatkm 
process is based upon (among other things) the tnist 
relatk)nship(s) in place between those two entities - the 
originator (signer) and the recipieni (verifier). 

Fig. 6 is a bloci( schematic diagram that illustrates 
trust between two entities according to the inventkm. In 
this situatbn. EntityA 70 has been Issued a certfficate 
by CAl 72, EntityB 74 has been issues a certiRcate by 
CA2 76, and OA's 1 and 2 have been cross certified. (A 
cross-certificate is a special type of certificate which in- 
dk:ates mutual trust between two CAs.) The resulting 
trust model sets up a path of trust between EntityA and 
EntityB. enabling them to verity digitally signed docu- 
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menls from one another successfully. (A trust model t$ 
comprised of the trust relationships among PKI entities 
(CAs and end users), entbodied by the certificates and 
cross-certificates Issues among these entities, as well 
as the underlying policies which enable this tmst.) Note 
that if any of the three paths in this model were not in 
place, then sufficient tnist would be lacking for the suc- 
cessful exchange of digitally signed messages between 
the two end parties. Signature verification would fail if 
any entity in this path is not tnjsted. 

This trust path is commonly referred to as the cer- 
tificate chain because d is composed of the certificates 
between the two entities. When considering the save 
state approach to long term signature verincation, it is 
this entire trust path (among other things) which must 
be archived as part of the PKI state for later signature 
reverificaiion. Moreover, the trust path stored by the 
LTSV facility must contain the relevant trust Information 
exIsUng at the time of the request, not at eome other 
lOTie (before or after) where the trust relationships may 
be different between the entities. For example, a cross 
certiTrcate between to CAs could either be created or re- 
moved at some point in time. This could effect the trust 
between two entitles and affect the outcome of a signa- 
ture verffication. 

As discussed above, the time as^ciated with the 
existing trust model between two entities is extremely 
important to the LTSV facility, but there are also ramifi- 
cations with respect to how the LTSV module works - 
spedficaHy. vwhat tmst infomiation Is needed and stored 
by the LTSV contponent for later signature verification. 
This gets compGcated when the LTSV component Is in- 
cluded, which may or tt^ not be trusted (via some trust 
path) by some entities. 

Consider the three scenarios illustiated in Rgs. 5a- 

5c: 

Scenario 1 is fairly slraightfonward. There are only 
two entities involved The tmst path stored by the LTSV 
facifity is the path between those two parties (EnlityA 
and LTSV). It is assumed that tmst exists between these 
entities, othenwise EntilyA would not submit a request 
tothatsen^ice. 

Scenario 2, however, raises certain issues. When 
EntityB sends a request to the LTSV sen^ice. what sig- 
nature does EntltyB want to later verify? Most likely. En- 
tityB wants to reverify EntltyA^ signature at a later tmne 
- it wants the LTSV senrlce to document that the signed 
document received from EntilyA was valid (contained a 
valid signature) at the time it was received. This raises 
two general questions: 

• Whether the LTSV sen^ice is tnjsted by EntityA. It 
can be assumed that the communicating parties 
(EntftyA with EntityB. and EntltyB with the LTSV) 
have developed some tmst between themselves. 
But in this case, it is possble that there exists no 
tmst path between EntityA and the LTSV compo- 
nent. 



• • The tmst path that is to be stored by the LTSV fa- 
cility. There exist three possible trust paths which 
can be stored by the LTSV /.e. the path between 
Entities A and B: the path between EntityB and the 
5 LTSV component Itself: and the path between Enti- 
tyA and the LTSV component, if it exists. 

Fig. 7 is a block schematic diagram that illustrates 
a long term signature verlTicalion trust model. Given ece- 

10 nario Z where EntltyB 64 submits a signed document, 
received from EntityA 80. to the LTSV component B3, 
the LTSV can save the trust model emboded in theorig- 
inal signed document (EnlityA 80 CA1 82 -> CA2 86 
-4 BitityB 84). Later verification of this signature recre- 

15 ates the verification process originally perfomfied by En- 
tityB when It received this document from EntityA. If. 
however, the PKI state stored by the LTSV sen/be were 
to contain only the trust path between me submitter and 
the senrice (Ent^ B4 •> CA2 66 -> CAS 90 -> LTSV 

20 88), then Teverifipallon of the original document, as orig- 
inally performed. Is impossible. In fact, this is exactly the 
paradigm described In ecenario 1 , where the trust path 
between the submitter and the LTSV are of interest 
The above discussion reveals that there are good 

2S reasons for the LTSV component to be able to store ei- 
ther tnjst path, depending upon the requirements of the 
client. 

In scenario 2, the LTSV would most ikety store the 
trust path oorre^xKiding to the message from EntityA 
30 to EntityB (to reverify the signed document from EntityA 
to EntityB). In scenario 1 . the LTSV would store the tmst 
path corresponding to the submission itself - from En- 
tityA to the LTSV. 

Similarty, scenario 3 represents a case where flex- 
es ibiDty in whk:h tmst path(s) to store Is required. In this 
case. EntltyA's submission to the LTSV faciliiy may be 
with the intent to either reverify Re correspondence wSh 
EntityB. or to reverify the submission itself (between En- 
tityA and the LTSV). In fact, both trust paths may be of 
40 use to the client The requirements on the LTSV are de- 
tennlned by the business of the partteu^r appBcatkm 
being deployed. For this reason, the interiace to the 
LTSV preferably supports the ability of the cfient to Indi- 
cate the needs in terms of trust paths as it impacts the 
45 requirements tor later reverificatlon. 

The disclosures in United Slates patent application 
no 08/892,792. from which this application dtalms prior- 
ity, and in the abstract accompariying this applteation 
are Incorporated herein by reference. 

so 

Clelme 

1. A method of enabling long term verifk»tion of digital 
55 signatures, comprising the steps of: 

submitting a source document or digest thereof 
to a signature verification entity, and 
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using an archive facility to etore a public key 
infrastructure ^Kl) state relative to said docu- 
ment at a selected archival time. 

2. A method as in claim 1 . comprising the steps of: 

using said archived PKi state to re-create said 
PKI state relative to said document at a select- 
ed time after a certificate associated with said 
signature has expired; 

wherein the time over which a digital signature 
. associated with said document can be verffied 
is extended beyond expiration of any or all of 
any certificates upon which that signature de- 
pends. 

3. A method as in claim i or 2 comprising the step of: 

storing said source document s^aiately from 
any associated cryptogiaphic infoimation. 

4^ A method as in claim 1, 2 or 3 wherein the selected 
archival time used as the basis for subsequent re- 
creation of a signature verification process is the 
time of said source document submittal 

is the time when said source document was 
signed by its originator; or in the time when said 
source document was verified by a recipienL 

5. A metliod as In any prececfing claim, comprising the 
step of; 

protecting said PKi state information from intrusion 
by maintaining it in a secure stoiage ladlily prefer- 
ably comprising of at least one of a firewall, access 
control mechanism, audit facility, Intnjsion detection 
facifity, physical isolation and network isolation; or 
protecting non-cryptograf^ic PKI state information 
from intrusion by prote^rig It in an archive via any 
of a si^ture and Iceyed hash algorithm. 
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chive facility once with an extremely long key. 

9. A n>ethod as in ar>y preceding claim, comprteing at 
least one of the steps of : 

protecting said archive facility Itseff. rather than 

' individual documents contained in said archive; 
and 

employing a cryptogiaphic protection mecha- 
nism at said signature verification entity. 

10. A method as in any preceding claim, comprising the 
step of: • 

using a time stamp facility to seal cryptographic in- 
formation in time. 

11. Apparatus for ksng term verification of digital signa- 
ture, comprising: 

a source document; and 
an archive tacflity for storing a public key infra- 
structure (PKI) state restive to said document 
at a selected archival tinna 

12. Appamtus as in claim 11, comprising: 

either of asignalure and a keyedbash eyetem 
for protecting non-cryptographic PKI state faiforma- 
tton from undetected modification, wherein said 
noncryptographic PKI state Information is main- 
tained in an archive. 



6. A method as in ariy preceding daim comprising the <o 
step of: 

providing utilfties for viewing said PKI state informa- 
tbn and for >^ually nipnitoring system security. 



A method as In any preceding claim, wherein class- 45 
es of PKI state information may include one or nK>re 
of certificate chain from one entity to another. In- 
cluding certificalkan authorities (OAs) and the end 
entities; certificate revocation Hsts (CRLjs), one for 
each OA In certificate chain; certifrcate practkre so 
statements; attribute certificates; policy constraints; 
trust informalbn; and date and time. 

A method as in any preceding daim. comprising the 
step of: 55 
periodically countersigning all data in need of cryp- 
tographs refresh through the use of nested signa- 
tures and/or countersigning informatun In said ar- 
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(57) The tome over which a digital signature can be 
verified is extended weD beyond the expiration oi any or 
all of the certificates upon which that signature depends. 
In a *save state' approach, an archive facility Is used to 
store public tcey hlrastructure (PICI) state, e.g. crypto- 
graphic inforniatlon. such as certificates and ceitificate 
revocation lists (CRI^), in addrlion to non-cryptographic 
"nJonmation, such as trust policy statements or the doc- 
ument itseM. This infomiation comprises all that is nec- 
essary to re-create the signature verification process at 
a later time. When a user wants to verify the signature 
on a document, possibly years later, a long term signa- 
ture verification (LTSV) sen^r recreates the precise 



slate of the PKI at the time the document was origlnaBy 
submitted The LTSV senrer restores the state, and the 
signature verification process executes the exact proc- 
ess it performed (or would have periormed) years ear- 
lier. Another embodiment of the invention combines the 
strength of cryptography with the proven resilience of 
(non-public liey) technology and procedures currently 
associated with secure data stores by saving the PKI 
state for future verification; and protecting the PKI state 
information from intrusion by maintaining it in a secure 
storage facility which is protected by sen^ices, such as 
firewalls, access control mechanisms, audit facifilies, in- 
Uusion detection fadrities, physical isolation, and net- 
woric isolation. 
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